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15 



Die vorliegende Erfindung befaflt sich mit Verfahren, far das 
Debuggen von Programmen auf konf igurierbaren Architekturen. 
20 Unter einer rekonfigurierbaren Architektur, werden Bausteine 
(VPU) mit konf igurierbarer Funktion* und/oder Vernetzung ver- 
standen, insbesondere integrierte Bausteine mit einer Mehr- 
zahl von ein- Oder mehrdimensional angeordneten arithmeti- 

•schen und/oder logischen und/oder analogen und/oder spei- 
25 chernden und/oder vernetzenden Baugruppen (im Folgenden PAEs 
genannt) und/oder koramunlkativen/peripheren Baugruppen (10), 
die direkt oder durch ein oder mehrere Bussystem(e) miteinan- 
der verbunden sind. PAEs sind beliebiger Ausgestaltung, Mi- 
schung und Hierarchie angeordnet, Diese Anordnung wird im 
30 w^iteren PAE-Array ocler PA genannt. 

Zur Gattung dieser Bausteine zahlen systolische Arrays, nsu- 
ronale Netze, Mehrprozessor Systeme, Prozessoren mit mehreren 
Rechenwerken und/oder logischen Eellen, Vernet zungs- und 
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Netzwerkbausteine wie z.B. Crossbar-Schalter, ebenso wie.be- 
kannte Bausteine der Gattung FPGA, DPGA, XPUTER, etc.- Hinge- 
wiesen wird insbesondere in diesem Zusammenhang auf die fol- 
genden Schutzrechte desselben Anmelders: P 44 IS 881-0-53, DE 
197 81 412-3, DE 197 81 483-2, DE 196 54 846.2-53, 
DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198 80 129.7, 
DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 00/01869, DE 100 
36 627-9-33, DE 100 28 397.7, DE 101 10 530.4, DE 101 11 
014.6, PCT/EP 00/10516, EP 01 102 674.7, PACT 28, PACT26/US, 
PACT19, PACT20, PACTll. Diese sind hiermit zu Of f enbarungs- 
zwecken vollumf Snglich eingegliedert . 

Weiterhin soli angemerkt werden, daB die verfahren auch auf 
Gruppen von mehreren Bausteinen angewendet werden kSnnen. 

Es werden mehrere Verfahren und Hardwareimplementierungen 
vorgestellt, die ein effizientes Debuggen von VPU-Systemen 
ermdglichen. 

20 Die Aufgabe der vorliegenden Erfindung besteht darin, Neues 
fur die gewerbliche Anwendung bereitzustellen . 

Die LSsung der Aufgabe wird unabh&ngig bsansprucht ♦ Bevorzug- 
te AusfUhrungsformen befinden sich in den Unteransprtichen. 

X. grfindunggqemaaeg Varffahren 

Das Debuggen erfolgt entweder durch die Verwendung eines ent- 
sprechend an eine VPU angeschlossenen Microcontrollers oder 
30 durch eine Ladelogik nach den Patenten PACT01, 02, 04, 05, 
09, 10, 11, 13, 17, die durch Bezugnahme vollumf Snglich ein- 
gegliedert sind. 
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Folgende grundlegenden Verfahren sollen dabei angewendet wer- 
den: 

1.1 Erkennen einer Debug-Bedtngung 

1.1.1 Bedinqunq 

Durch den Programmierer wird beispielsweise innerhalb des De- 
bug-Tools eine Oder mehrere Bedingungen festgelegt, die das 
Debugging starten (vgl Breakpoint nach dem Stand der Tech- 
nik) . Das Auf treten der Bedingungen wird zur Lauf zoit in der 
VPU und/oder einem beliebigen mit der VPU datenaustauschenden 
GerMt f estgestellt * Dies geschieht beispielsweise durch das 
Auftreten von bestimmten Datenwerten bei bestimmten Variablen 
und/oder bestimmten Triggerwerten bei bestimmten PAEs. 

1.1.2 Vorbedingung 

Im Optimalfall kann eine bestimmte Bedingung gemafc o.g. Defi- 
nition bereits mehrere Takte vor dem Eintreffen der Debug- 
Bedingung durch den Programmierer festgelegt werden. Dadurch 
werden bestimmte Latenz-Probleme die im Folgenden diskutiert 
warden von vornherein ausgeschlossen. 

Es sollen im folgenden zwei grundlegende Arten des Debuggings 
fttr VPUs diskutiert werden, wobei die jeweils bevorzugt ari2u- 
wendende Methode von der Wahl des Compilers abhangt: 
Far Compiler, die Code auf Basis von instantiierten Modulen 
einer Hardwarebeschreibungssprache (oder ahnlichen Sprache) 
generieren, kann sich besonders die im Folgenden beschriebene 
Methode A eignen. 

FUr Compiler ahnlich PACT11, die komplexe Instruktionen er- 
zeugen und nach einem VLIW-Shnlichen Verfahren generieren, 
eignet sich besonders die im Folgenden beschriebene Methode 
B. Grunds^tzlich ist ftir den Betrieb als Prozessor oder Co- 
prozessor Methode B die bevorzugt anzuwendende. 



3 
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Es wurde erkannt, dass insbesondere die Verwendung beider Me- 
thoden A und B gemeinsam, zu den besten und transparentesten 
Debuggingergebnissen fuhrt. insbesondere kann je nach Tiefe 
des zu debuggenden Pehlers zunSchst unter Zuhilfenahme der 
schnellen Debuggingmethode B debuggt werden und nach hinrei- 
chende Lokalisierung des Fehlers sodann per Methode A die De- 
tails in der "Tiefe" analysiert werden. 

2, Methode A 

2.1 Gmndprinzip 

Nach dem Auftreten einer (Vor) Bedingung wird die VPU angehal- 
ten. Danach warden die relevanten Debug-Inf ormationen aus den 
PAEs an das Debug- Programm ttbertragen. Die relevanten Debug- 
Informationen wurden zuvor durch den Programmierer innerhalb 
des Debug-Programmes festgelegt. Nach Auslesen aller relevan- 
ter Debug- Informationen wird der nachste Takt ausgeftihrt und 
erneut die relevanten Debug-Inf ormationen ausgelesen. Dies 
wiederholt sich solange, bis der Programmierer den Debug- 
Vorgang abbricht, 

2.2 Uxxterstutzung durch die Hardware 

2.2,1 Auslesen der Register 

Wesentlich iUr die Funktionsweise des Debuggers ist die M6g- 
lichkeit durch eine ttbergeordnete Einheit (im Polgenden De~ 
bugProzessor (DB) genannt) , also beispielsweise eine CT oder 
Ladelogik, oder einen anderen extern angeschlossenen 
(Host) Prozessor, die internen Datenregister und/oder Status- 
register und/oder Zustandsregister und ggf . je nach Implemen- 
tierung weitere relevanten Register und/oder Signale aus den 
PAEs und/oder dem Netzwerk zurttckzulesen (zusammengef afit im 
Folgenden als Debuginf ormation bezeiohnet) „ Eine derartige 
MBglichkeit ist z.B. mit der in PACT08/PCT geschaffenen Ver- 
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bindung zwischen der Ladelogik und dem Datenbus einer PAE 
(PACT08/PCT 0403, Fig, 4) realisierbar . 

Es soli ausdrUcklich angemerkt sein, dafc auch serielle Ver- 
fahren zum Auslesen der Register verwendet werden kSnnen. 
5 Beispielsweise kann JTAG gewahlt werden und der DB ttber die- 
ses Verfahren ggf. auch als externes seperates und evtl. auch 
marktttbliches Gerat (z.B. Firma Hitex, Karlsruhe) angeschlos- 
sen sein. 

Da bevorzugt auf samtliche Register, oder zumindest eine er- 

10 heblich Anzahl derer, durch den Debugger schreibend und/oder 
lesend zugegriffen werden kann, kann optional und bevorzugt 
ein wesentlicher Teil der (seriellen) Verkettung der Register 
zu Testzwecken (Scan-Chain) far die Produktionstests des 
Chips entfallen. Die Scan-Chain wird normalerweise daftir ver- 

15 wendet, urn alle Register innerhalb eines. Chips w&hrend der 
Produktionstests mit Testdaten vorladen zu kdnnen und/oder 
die Inhalte der Register zu Testzwecken wieder zurtickzulesen. 
Das Vorladen und/oder Zurticklesen geschieht dabei typischer- 
weise durch Testsysteme {z.B. SZ Testsysteme, Amerang) 

20 und/oder gemafc den in PACT 09 beschriebenen Verfahren. Die 

Scan-Chain bentftigt dazu einen zusatzlichen nicht unerhebli- 
chen Hardware- und Fl&chenaufwand £tir jedes Register. Dieser 
kann nunmehr, zumindest far die Register die debugbar sind, 
entfallen, wenn - wie erf indungsgem^B vorgeschlagen - die 

25 Produktionstestanlagen Uber geeignete Schnittstellen (z.B. 

parallel, seriell, JTAG, etc) Zugriff auf die Register erhal- 
ten* 



30 2.2.2 Anhalten Oder Verlanqsamen des Taktes 

Durch das Auftreten von Bedingung und/oder Vorbedingung kann 
der Takt entweder angehalten oder verlangsamt werden, urn hin- 
reichend Zeit zum Auslesen zur VerfUgung zu stellen. Ausge- 
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15st wird dieser Debugbeginn entweder dlrekt durch eine PAE, 
die die (Vor) Bedingung (en) berechnete oder durch eine ttberge- 
ordente Einheit (z.B. Ladelogik/CT, Hostprozessor) aufgrund 
beliebiger Aktionen, beispielsweise durch die Information, 
dafi an einer PAE ©in© (Vor ) Bedingung auftrat und/oder durch 
eine Aktion innerhalb des DebugProzessors und/oder durch ein 
beliebiges Programm und/oder eine beliebige externe/periphere 
Quelle. Zum Informieren stehen Triggermechanisraen entspre- 
chend PACT01, PACT02, PACT08/ PACT10, PACT12, PACT 17 zur Ver- 
fUgung. 

Sofern der Takt verlangsamt wird, muss durch den Debugprozes- 
sor innerhalb des verlangsamten Zyklus des Verarbeitungstak- 
tes alls relevante Debug-Information aus den PAEs ausgelesen 
werden. Dazu 1st es sinnvoll und bevorzugt, den Takt nur par- 
tiell zu verlangsamen, also den Arbeitstakt zu senken oder 
anzuhalten, aber den Takt fttr den Auslesemechanismus weiter 
fortzufahren. Desweiteren ist es sinnvoll und bevorzugt gene- 
rell die Register zum Datenerhalt mit Takt zu versorgen. 

Nach dem Anhalten des Taktes kann ein Single-Step Modus rea- 
lisiert werden, d.h. der Debugprozessor halt den Verarbei- 
tungstakt so lange an, bis er alle Debug-inf ormation ausgele- 
sen hat, Danach startet er den Verarbeitungstakt wieder fur 
einen Zyklus und halt ihn erneut bis nach dem Auslesen aller 
relevanten Debug-Informationen an, 

Der Aualesetakt und der Takt des Debug-Prozessor$ sind bevor- 
zugt unabhangig vom Verarbeitungstakt der PAEs r sodaft die Da- 
tenverarbeitung von dem Debugging und insbesondere Auslesen 
der Debug-Inf ormation getrennt ist. 

Hardwaretechnisch wird das Anhalten oder Verlangsamen des 
Taktes durch Methoden nach dem Stand der Technik, wie bei- 
spielsweise Gated-Clocks und/oder PLLs und/oder Teller oder 
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andere Verfahren erreicht. Diese Mittel werden bevorzugt an ■ 
geeignaten Stellen (Knoten) innerhalb des Clock-Trees einge- 
fttgt, sodass eine globule Taktsteuerungen der jeweils tiefer- 
liegenden Zweige realisierbar ist. 

5 Besonders bevorzugt ist das Versenden einer Taktsteuer- 
Information von einer ttbergeordneten Einheit (z.B. L&delo- 
gik/CT, Hostprozessor) an sSmtliche PAEs. Dies kann bevorzugt 
uber das Konf iguration$bussystem erfolgen. Die Taktsteuerin- 
forroation wird typischerweise gebroadcastet ubertragen, d.h. 

10 alle PAEs erhalten dieselbe Information. 

Beispielsweise konnen folgende Taktsteuerinf ormationen imple- 
ment iert sein: 

STOP: Der Arbeit stakt wird angehalten. 

SLOW: Der Arbeit stakt wird verlangsamt. 

15 STEP : Exakt ein Verarbeitungsschritt (Single Step Modus) 

wird ausgeftthrt und dann der Arbeit stakt wieder angehalten. 
STEP(n): n Verarbeitungsschritte wird ausgeftihrt und dann 
der Arbeit stakt wieder angehalten. 
GO: Der Arbeitstakt lauft normal weiter. 

20 Es soil insbesondere erwahnt sein, dass das Verfahren der 

Taktabschaltung und/oder Verlangsamung ebenso eingesetzt wer- 
den kann, urn den Stromverbrauch zu reduzieren. Sofern tempo- 
rSr keine Rechenleistung bentttigt wird, kann ein "Sleepmode" 
beispielsweise durch das Abschalten des Arbeitstaktes (STOP) 

25 oder durch spezielle Befehle (SLEEP) realisiert werden. Wird 
nicht die voile Rechenleistung benStigt, kann der Takt durch 
die Verwendung von SLOW verlangsamt warden und/oder temporar 
durch STEP(n) ausgesetzt warden. Insoweit ist das Verfahren 
optional Oder zus&tzlich zu den in PACT 15 beschriebenen Ver- 

30 fahren zur Reduzierung der Verlustleistung einsetzbar. 

Sin Problem des Broadcastings von Taktsteuerinf ormationen ist 
die Obertragungszeit des Broadcastes durch das Array aus 
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PAEs. Die Obertragung kann bei hoheren Taktfrequenzen nicht 
innerhalb eines Arbeitstaktes erfolgeh. Es ist aber zwingend 
notwendig, dass samtliche PABs zur gleichen Zeit auf die 
Taktsteuerinformationen reagieren. Bevorzugt wird die Takt- 
5 steuerinf ormation daher tiber ein gepipelintes Bussystem &hn- 
lich des in PACT17 beschriebenen CT-Bussystems tibertragen* 
Weiterhin wird ein Zahlenwert (LATVAL) den Taktsteuerinforma- 
tionen hinzugefttgt der gleich oder grtifter der maximalen Lange 
der Pipeline des Bussystems ist. In jeder Pipelinestuf e wird 

10 taktweise der Zahlenwert dekrementiert (Subtraction von 1) . 
Jede PAE die die Taktsteuerinformation erhalt dekrementiert 
im Weiteren den Zahlenwert mit jedem Takt. Damit ist sicher- 
gestellt, dass der Zahlenwert in dem gepipelinten Bussystem 
und den PAEs die die Taktsteuerinformation bereits empfangen 

15 haben immer exakt gleich ist, Erreicht der Zahlenwert den 

Wert 0 ist sichergestellt dass alle PAEs die Taktsteuerinfor- 
mation erhalten haben, Jetzt tritt die Taktsteuerinformation 
in Kraft und das Verhalten des Taktes wird entsprechend modi- 
f iziert * 

20 Durch das beschriebene Verfahren entsteht sine weitere La- 

tenzzeit (Latency) - Diese kann beispielsweise durch die nach- 
folgend beschriebene Registerpipeiine zusStzlich abgefangen 
werden Oder, wie besonders bevorzugt, durch die Definition 
der (Vor) Bedingung abgefangen werden, indem die 

25 (Vor) Bedingung soweit vorgesetzt wird, dass die Latenzzeit 
bereits berticksichtigt ist. 

Es soil besonders erw&hnt werden, dass die Latenzzeit im Sin- 
gle-Step Modus vernachlassigbar ist, da sie nur bei der Ab- 
schaltung es Taktes (STOP) eine Roll© spielt. Da der Befehl 
30 jSTEP immer nur exakt einen Schritt ausftthrt kommt es wShrend 
des Single-Step Betriebes durch keinerlei Verfaischung (Ver- 
zogerung) der Debugdaten durch die Latenzzeit* 
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2.2-3 Register-pipeline zum Ausqleichen der Latency 
Bei hoheren Betriebsf requenzen kann es zu einer Latenzzeit 
zwischen dem Erkennen des Debugbeginns und dem Anhalten Oder 
Verlangsamen des Taktes' kommen. Diese Latenzzeit ist exakt 
vorherbestimmbar, da die Position der verzSgernden Register 
in der VPU durch Hardware und/oder den zu debuggenden Algo- 
rithmus definiert und durch den Debugger daher exakt bere- 
chenbar ist. 

Durch die Latenzzeit verschieben sich jedoch die dem Debug- 
Prozessor zur Verfligung ge$tellten Inf ormationen derart, daft 
nicht mehr die korrekten Debuginf ormationen ausgelesen werden 
konnen* Bevorzugt wird dies durch ein entsprechende$ festle- 
gen der (Vor) Bedingung durch den Programmierer gelSst* 
Optional kann durch das Einftigen eines mehrstufigen Register- 
pipeline, die die Debuginf ormation in jedem Takt um ein Regi- 
ster weiter tibertr&gt, der Debugprozessor auf soviele Takte 
an Debuginformationen zuruckgreifen, wie die Registerpipeline 
lang ist. Die Lange der Registerpipeline ist so auszulegen, 
dass sie der maximal zu erwartenden Latenz entspricht* 
Aufgrund der exakten Berechenbarkeit der Latenzzeit ist es 
nunmehr dem Debug- Programm mGglich die zeitlich korrekte re- 
levante Debug-Inf ormation aus der Registerpipeline auszule- 
sen. 

Ein auftretendes Problem bei der Verwendung von Registerpipe- 
lines ist, dass diese verhaitnismaBig lang und damit, bezogen 
auf die fttr die Realisierung notwenige Siliziumf l&che, teuer 
sind. 

2 . 3 sicht^are Debug- infoxmationen 

Bei dieser Methode wird im Wesentlichen nach Auftreten der 
(Vor) Bedingung debugt, da erst danach in der Takt verlangsamt 
oder angehalten wird und das Auslesen der Debug-Inf ormation 
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erfolgt, Debug-Informationen die vor dem Auftreten der 
(Vor)Bedingung liegen sind daher zunSchst nicht sichtbar. 

Es ist jedoch, wenngleich auch unter Verlust an Arbeitslei- 
stung, m6glich eine VPU sofort vom Start einer Application an 
mit verlangsamten Takt oder Single-Step-Modus zu betreiben. 
Vom Start an werden die relevanten Debug-Informationen vom 
Debug-Pro2essor ausgelesen« 

3. Methode B 
3.1 Grundprinzip 

Relevanten Debug-Informationen aus den Speichereinheiten, die 
gemSB PACT01, 04, 13, 11, 18 die Anwendungsdaten und Zustande 
eines bestimmten Arbeitsschrittes beinhalten an das Debug- 
Programm tibertragen* Diese Speichereinheiten, nachfolgend 
auch Arbeitsspeicher genannt, arbeiten im Maschinenmodell 
nach PACT01, 04, 11, 13, 18 quasi als Register zur Speiche- 
rung von Daten, die innerhalb eines Konf igurationszykluses im 
PA oder Teilen des PAs berechnet wurden. Es wird insbesondere 
auf die Patentanmeldung PACT11 verwiesen, in der die Verwen- 
dung der Speichereinheiten als Registers (REG) 2ur Relisie- 
rung eines Prozessormodells detailliert beschrieben ist. 
PACTll ist zu Of f enbarungszwecken vollumf anglich eingeglie- 
dert. Eine Speichereinheit besteht dabei aus einer beliebigen 
Anordung und Hierachie von unabhangigen und abhangigen Spei- 
chern. Es ist moglich gleichzeitig mehrere unterschiedliohe 
Algorithmen auf dem PA auszufdhren, die dann unter schiedliche 
Speicher verwenden. 

Wesentlich fur die Anwendung dieser Methode ist, class Daten 
und/oder algorithmisch relevant© Zust&nde in die den PAEs zu- 
geordneten Speichereinheiten abgelegt sind. Wobei eine Spei~ 
chereinheit jeweils zumindest derart dimensioniert ist, daii 
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alle relevanten Daten und/oder Zust&nde eines Zyklus gespei- 
chert werden kSnnen; wobei die LSnge eines Zyklus durch die 
Gr515e der Speichereinheit bestimmt sein kann und bevorzugt 
auch bestimmt ist (vgl, PACT04 ) ♦ 

5 

Unterschiedliche Daten und/oder Zustande warden derart in die 
Speichereinheiten gespeichert, daft diese eindeutig dem Algo- 
rithmus zugeordnet werden konnen* Dadurch kann der Debugger 
die relevanten Daten und/oder Zust&nde (Debug- In format ion) 
10 eindeutig identif izieren. 




Die relevanten Debug- Inf ormationen kdnnen - insbesondere auch 
vorab - durch den Programmierer innerhalb des Debug- 
Programmes festgelegt warden. Diese Debug-Inf ormationen wer- 



15 den aus den Speichereinheiten ausgelesen. Dazu stehen unter- 
schiedliche Methoden zur VerfUgung, einige Mdglichkeiten wer- 
den nachfolgend nahers beschrieben. Nach dem Auslesen aller 
relevanter Debug-Informationen wird der n&chste Konfigurati- 
onszyklus ausgeftihrt und erneut die relevanten Debug- 

20 Informationen ausgelesen. Dies wiederholt sich solange, bis 
der Programmierer/Debugger den Debug-Vorgang abbricht. 

Mit anderen Worten, werden die relevanten Daten und/oder Sta- 
tusinformationen nicht taktweise sondern konf igurationsweise 

• 25 an den Debugger Ubertragen. Dies geschieht aus den Spei- 
chereinheiten/ die mit den Registern einer CPU vergleichbar 
sind. 



30 3.2 Un-fcers-tUtzurig durch die Hardware 

Wesentlich far die Funktionsweise des Debuggers ist die MSg- 
lichkeit durch die CT oder einen anderen extern angeschlosse- 
nen Prozessor <im Folgenden DebugProzessor (DB) genannt) , 

U 
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die, beispielsweise auch interne (n), Arbeitsspeicher der VPU 
2U lesen. Eine derartige MSglichkeit ist z.B. durch den An- 
schluii der CT an die Arbeitsspeicher zum Vorladen and Lesen 
der Daten und/oder durch die in PACT 13 beschriebene Verfahren 

5 sum Herausschreiben der internen Speicher an externe Speicher 
gegeben. In einer m6gliche Ausgestaltung kann auf Arbeits- 
speicher durch verschieden Verfahren nach dem Stand der Tech- 
nik (z.B. Shared Memory, Bank Switching) derart voia DebugPro- 
2essor 2ugegriffen werden, dass der Datenaustausch mit dem DB 

LO weitestgehend unabhSngig von einer weiteren Datenverarbeitung 
in der VPU erfolgen kann. 




In einer meglichen Ausgestaltung kann z.B. entsprechend Me- 
thode A durch eine Oder mehrere der vorstehend beschriebenen 



15 Mafcnahmen der Takt der vpu sum Auslesen der Speicher gegebe- 
nenfalls entweder entsprechend verlangsamt oder angehalten 
werden und/oder gegebenenf alls im Single-Step-Modus betrieben ' 
werden. Dabei kann je nach Implement ierung der Arbeitsspei- 
cher, z.B, bei Bank-Switch Verfahren auf einen besondere Ein- 

20 griff in den Takt verzichtet werden. 

Typischerweise geschieht das Anhalten oder Verlangsamen des 
Taktes nach Methode B und das Auslesen und/oder Kopieren 
und/oder Umschalten der Arbeitsspeicher nur, wenn ein Daten- 
verarbeitungszyklus bzw. Konf igurationszyklus beendet ist* 

25 

Mit anderen Worten ist ein wesentlicher Vorteil von Methode 
B, dass keine besondere Untersttttzung durch die Hardware er- 
forderlich ist. 

In einer raOglichen Ausgestaltung mufi ein DB lediglich Zugriff 
30 auf die Arbeitsspeicher besitzten. 

In einer besonders zu bevorzugenden Ausgestaltung geschieht 
der Zugriff auf die Arbeitsspeicher durch eine geeignete Kon- 



12 
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figuration der VPU, die dadurch die Arbeitsspeicher selbst&n- 
dig und ohne Modifikation ausliest und an einen DB iibertragt. 

3,3 Zugri££ auf Debiag-Inf ormation 

In PACT01 # PACT04, PACTll, PACT 13 sind Datenverarbeitungsver- 
fahren beschrieben, bei denen zyklisch eine Menge an Opera- 
tionen auf einen rekonf igurierbaren Datenverarbeitungsbau- 
stein abgebildet werden, In jedem Zyklus wird eine Mehrzahl 
von Da ten berechnet, die von einer peripheren Quelle und/oder 
einen internen/externen' Arbeitsspeicher stammen und an eine 
peripheren Quelle und/oder einen internen/externen Arbeits- 
speicher geschrieben werden, Dabei kGnnen jeweils unter- 
schiedliche und/oder vor allem mehrere unabhSngige Arbeits- 
speicher gleichzeitig verwendet werden. 

Beispielsweise kSnnen in diesem Datenverarbeitungsverfahren 
die Arbeitsspeicher Oder ein Teil der Arbeitsspeicher als Re- 
gisters at z dienen. 

Nach PACT11 und PACT 13 werden dabei samtliche Daten und Zu- 
stSnde die fttr die weitere Datenverarbeitung relevant sind in 
die Arbeitsspeicher abgelegt oder aus selbigen gelesen. 
In einem bevorzugten Verfahren werden fur die weitere Daten- 
verarbeitung irrelevante Zusta.nde nicht gespeichert. 

• 25 Die Unterscheidung zwischen relevanten und irrelevanten Zu- 
standen soil an folgendem Beispiel aufgeseigt werden, es soil 
zu Offenbaxungezwecken lnsbesondere auf die Ausfiihrungen in 
PACT11 verwiesen werden: 

Die Zustandsinformation eines Vergleichs ist beispielsweise 
30 far die weitere Verarbeitung der Daten wesentlich, da dieser 
die auszufUhrenden Funktionen bestimmt. 

Ein sequentielle Dividierer entsteht beispielsweise durch Ab- 
bildung eines Divisionsbef ehles auf eine Hardware, die nur 

13 
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die sequentielle Division unterstutzt. Dadurch entsteht ein 
Zustand der den Rechenschritt innerhalb der Division kenn- 
zeichnet , Dieser Zustand 1st irrelevant, da far den Algorithm 
mus nur das Ergebnis (also die ausgeftihrte Division) erfor- 
5 derlich ist. In diesem Fall werden also lediglich das Ergeb- 
nis und die Zeitinformation (also die Verfugbarkeit) benO- 
tigt. 

Die Zeitinformation ist beispielsweise in der VPU-Technologie 
nach PACT01, 02, 13 durch das RDY/ACK Handshake erh&ltlich. 
10 Hierzu ist jedoch besonders anzumerken, dass das Handshake 

ebenfalls keine relevanten Zustand darstellt, da es lediglich 
die Gaitigkeit der Daten signalisiert r wodurch sich wiederum 
die verbleibende relevate Information auf die Existenz gttlti- 
ger Daten reduziert. 

IS 

in PACT11 wird sine Unterscheidung swischen lokal und global 
relevanten Zust&nden aufgezeigt: 

lokaX: Der Zustand ist nur innerhalb einer einzigen abge- 
schlossenen Konf iguration relevant, Daher mufi der Zustand 
20 nicht zwingend gespeichert werden. 

global: Die Zustandsinformation wird fur mehrere Konfigura- 
tionen bendtigt, Der Zustand muli gespeichert werden, 

Es ist nunmehr denkbar, dafi der Programmierer einen lokal re- 
25 levant en Zustand debuggen will, der nicht in den Speichern 
abgelegt ist. 

In diesem Fall kann die Applikation dahingehend modifiziert 
werden, dafi eine Debug-Konfiguration entsteht (Equivalent zum 
Debug-Code von Prozessoren) , die eine Modifikation zum "nor- 
30 nialen" Code der Applikation derart aufweist, dafi dieser Zu- 
stand zusatziich in die Speichereinheit geschrieben und damit 
dem Debugger zur Verftfgung gestellt wird, Dadurch entsteht 
eine Abweichung zwischen Debug-Code und tatsSchlichen Code, 

14 
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die zu einem unterschiedlichen Verhalten der Codes ftthren 
kann. 

In einer daher besonders bevorzugten Ausftihrung wird keine 
Debug-Konf iguration verwendet. Vielmehr wird die zu debugger*- 
de Konf iguration derart terminiert, dass die fur Debugging- 
zwecke zusatzlich erf orderlichen Daten die Terminierung Qber- 
dauern, d.h. weiterhin gtiltig in den entsprechenden Speicher- 
stellen (REG) (z.B. Register, Zahler, Speicher) verbleiben* 



Eine Konf iguration wird geladen, diese verblndet die REG in 
geeigneter Weise und definierter Reihenfolge mit einem oder 
mehreren globalen Speicher (n) auf die der DB Zugriff hat 
(z.B. Arbeitsspeicher) • 

15 Die Konf iguration kann beispielsweise Adressgeneratoren ver- 
wenden urn auf den/die globalen Speicher zuzugreifen. 
Die Konf iguration kann beispielsweise Adressgeneratoren ver- 
wenden urn auf als Speicher ausgestaltete REG zuzugreifen. 
Entsprechend der konf igurierten Verbindung zwischen den REG 

20 werden die Inhalte der REG in einer definierten Reihenfolge 
in den globalen Speicher geschrieben, wobei die jeweiligen 
Adressen von Adressgeneratoren vorgegeben werden. Der Adress- 
generator generiert die Adressen ftir den/die globalen Spei- 
cher (n) derart, dass die beschriebenen Speicherbereiche (DE- 

25 BUGINFO) der entfernten zu debuggenden Konf iguration eindeu- 
tig zugeordnet werden kannen. 

Das Verfahren entspricht dem Kontext -^switch in PACT 15 und 
FACTll die zu Of fenbarungs2wecken vollumf Snglich eingeglie- 
dert sind. 

30 Der DB kann nunmehr auf die Daten innerhalb eines ihm zugSng- 
lichen Speicherbereiches (DEBUGINFO) zugreifen. 
Soil das Debugging -mittels eines Single-Step Verfahrens 
durchgeftihrt werden, kann nach jedem single step einer *u de- 

15 
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buggenden Konf iguration ein Kontext-Switch derart durchge- 
ftlhrt werden, dass samtliche Daten erhalten bleiben und die 
zu debuggende Information aus den REG in einen Arbeitsspei- 
cher geschrieben wird. Sodann wird wiederum unter Erhalt der 
5 Daten die zu debuggende Konf iguration wieder konfiguriert und 
far einen weiteren single step ausgeftthrt. Dies geschieht far 
jeden zu debuggenden single step der zu debuggenden Konf igu- 
ration* 

3.4 Sichtbare Debug- Ia£ormationen 

Ein Debuggen vor der (Vor) Bedingung kann vergleichsweise ein- 
fach und ohne grofie Perf ormance-Verluste durchgefahrt werden, 
da die ben&tigten Debug-Informationen in Arbeitsspeicher ver- 
ftigbar sind. Durch das Ubertragen der Arbeitsspeicher in an- 
dere Speicherbereiche, auf die der DB bevorzugt direkten Zu- 
griff hat, kann die Debug-Information einfach sichergestellt 
werden. Eine noch schnellere Methode ist, die Arbeitsspeicher 
durch ein Bank-Switching Verfahren (nach dem Stand der Tech- 
nik) derart zwischen den einzelnen Konf igurationen umzuschal- 
ten, dafi die Debug- Information in einer jeweils neuen Bank 
liegt. Das Umschalten kann sehr zeitoptimierend, im Optimal- - 
fall sogar ohne Auswirkung auf die Verarbeitungsleistung er- 
folgen* 




4. Funk-fciongweige des Debuggers 

30 Das Debugger Programm selbst kann auf einem DB aufierhalb des 
PA's ablaufen. Alternativ da2u kann eine VPU selbst den DB 
darstellen, entsprechend der Methoden, die bel Prozessoren 
angewendet werden. Dazu kann ein Task- oder Kontextswitch 
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(SWITCH) entsprechend den AusfOhrungen in PACT11 ausgefiihrt 
werden. Die Debugxnf ormationen des zu debuggenden Programmes 
werden bei einem SWITCH zusammen mit den relevanten Daten ge- 
sichert und das Debugger Programm geladen, das die Informa- 
5 tionen auswertet und/oder interaktiv mit dem Programmierer 
verarbeitet. Danach wird erneut ein SWITCH durchgefUhrt (bei 
welchem die relevanten Inf ormationen des Debuggers gesichert 
werden) und das zu debuggende Programm wird weitergef uhrt . 
Die Debug-lnformation wird von Debugger entsprechend Methode 

10 A und/oder B gelesen und in einen von der Datenverarbeitung 
separaten Speicher und/oder Speicherbereich gespeichert, auf 
den der DB bevorzugt direkten Zugriff besitzt. 
Durch das Debugger-Programm werden die Breakpoints und 
(Vor) Bedingungen definiert. Ebenfalls kann das Debugger- 

15 Programm die Kontrolle ttber die Ausftihrung der Applikation, 
insbesondere den Ausfiihrungsstart und das Ausftthrungende 
ubernehmen . 

Der Debugger stellt dem Programmierer eine geeignete Arbeit- 
sumgebung zur Verfttgung mit ggf. graphischer Oberflache* In 

20 einer besonder bevorzugten Ausftthrung ist der Debugger in ei- 
ne komplexe Entwicklungsumgebung integriert und tauscht mit 
dieser Daten und/oder Steuerinformation aus. Insbesondere 
kann der Debugger die aus den Arbeitsspeichern gelesenen Da- 
ten zur beliebigen Weiterverarbeitung auf einen Datentrager 

25 (Festplatte, CDROM) speichern und/oder innerhaib eines Netz- 
werkes (Ethernet) ablaufen. 

Der erfindungsgemafte Debugger kann zudem gemaB PACT 20 inner- 
haib einer Entwicklungsumgebung mit anderen Werkzeugen und 
insbesondere auch Debuggern kommunizieren; wobei in einer be- 
30 vorzugten Ausgestaltung die Steuerung und/oder Definition der 
Debugparameter von einem anderen Debugger aus tlbernomruen wer- 
den kann. Ebenso kann der Debugger die von ihm generierte De- 

!7 
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bug-Information einem anderen Debugger zur Verfttgung stellen 
und/oder von diesem dessen Debug-lnf ormation erhalten. 
Insbesondere das Feststellen des Auftretens von Breakpoints 
und/oder (Vor) Bedingung i$t durch einen anderen Debugger aus, 
bzw. den Einheiten die dieser andere Debugger debugt, durch- 
ftihrbar. Der erf indungsgemaJJe Debugger und die VPU reagieren 
dann entsprechend. 

Der andere Debugger kann insbesondere der Debugger eines ei- 
ner VPU zugeordneten anderen Prozessors sein, 
Der andere Debugger kann insbesondere der Debugger eines mit 
einer VPU gekoppelten anderen Prozessors (CT, bzw. ARC bei 
Chameleon) sein. 

Insbesondere kann der andere Debugger auf einem der VPU zuge- 
ordneten und/oder gekoppelten Prozessor ablaufen und/oder der 
zugeordnete Prozessor der DB sein f beispielsweise eine CT, 
bzw. ARC bei Chameleon. In einer besonders bevorzugten Ausge- 
staltung kann der zugeordnete Prozessor ein Rost-Prozessor 
sein, wie beispielsweise in PACT26/US und/oder PACT 2 8 be- 
schrieben. 



5. Beweg-txmg der Sfethoden 

Die Methode A ist erheblich zeit- und ressourcenintensiver 
als die Methode B, bei der kaum zusatzliche Hardware erfor- 
derlich ist und zudem ggf . das zeitaufwendige Auslesen der 
Debug-lnf ormation vom Start der Applikation an entfMllt. Da- 
her ist Methode B grundsatzlich vorzuziehen. Ftir Compiler 
nach PACT11 ist die Methode B eindeutig zu pr&f erieren. 
Es wurde erkannt, dass insbesondere die Verwendung beider Me- 
thoden A und B gemeinsam, zu den besten und transparentesten 
Debuggingergebnissen ftthrt. Insbesondere kann je nach Tiefe 
des 2U debuggenden Fehlers zun&chst unter Zuhilfenahme der 
schnellen Debuggingmethode B debuggt werden und nach hinrei- 

st»tm 

18 



)atum 27.08.02 16:09 FAXG3 Nr: 569608 von NVS:FAXG3.I0.0201/07214839850 (Seite 19 von 36) 



27-RUG-2002 16s 16 PRT.-flNW. P. P I ETRUK +4^ r^i ^to^wa o.kaa 





Akte: PACT 2 1 



chende Lokalisierung des Fehlers sodann per Methode A die De- 
tails in der "Tiefe" analysiert werden. 



5 6. Mixed Mode Debugger 

Bei der Anwendung der besonders bevorzugten Methods B kann es 
zu dem Problem kommen, dass die in den Speichern befindliche 
sichtbare Information nicht hinreichend ist. 
Typischerweise kann ein detaillierteres Debugging folgender- 
10 massen erfolgen: 

a) Die sichtbare Debuginf ormation (PRE INFO) vor der Konfigu- 
ration einer einen Breakpoint enthaltenden Konf iguration wird 
geslchert. Bei Auftreten eines Fehlers bei dem Breakpoint 
wird die dann sichtbare Debuginf ormation (POSTINFO) gesi- 

15 chert. Basierend auf der PRE INFO Information wird ein Soft- 
ware-Simulator gestartetdie zu debuggende (n) Konf igurati- 
on(en), simuliert. Der Simulator kann dabei jeden Wert inner- 
halb der PAEs und der Bussysteme bestimmen und (ggf. auch 
graphisch und/oder textuell) ausgeberi, wodurch ein detail- 

20 lierter Einblick in den Ablauf des Algorithmus zum Zeitpunkt 
des Auftretens des Fehlers erreicht wird* Insbesondere ist es 
mdglich die jeweils simulierten Werte mit den Werten von PO- 
STINFO zu vergleichen um Differenzen schnell zu erkannen. 

b) Die sichtbare Debuginf ormation vor einem Breakpoint wird 
25 gesichert. Bei Auftreten eines Breakpoints wird basierend auf 

dieser Information ein Sof tware-Visualisierer gestartet. Der 
zu debuggende Baustein wird nunmehr in einem Single-Step Ver- 
fahren betrieben, das das Auslesen samtlicher relevanter Da- 
ten nach Methode A ermoglicht. Diese Daten kdnnen nunmehr 
30 entweder direkt (ggf. auch graphisch und/oder textuell) aus- 
gegeben werden und/oder an einen Simulator weitergeleitet 
werden, dessen Simulation sodann auf den detaillierten Daten 
beruht, und danach wie bekannt ausgegeben werden- 

19 
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6*1 Vortoile eines Mixed Mods Debuggers 

Der Mixed Mode Debugger ermaglicht die detaillierte Analyse 

5 der Ablaufe innerhalb eines Bausteines* Durch die MSglichkeit 
gem&ii Methode B bis zu einem gesetzten Breakpoints mit voller 
Geschwindigkeit zu arbeiten und danach ggf . an2uhalten 
und/oder ggf. in einen Single-Step Modus zu gehen, wird das 
Debugging zeitef f izient , wodurch das Testen grofter Datenmen- 

10 gen und/oder komplexer Algorithmen ermttglicht wird. 

Das bevorzugte Aufsetzen eines Simulators nach dem Auftreten 
des Breakpoints auf Basis der aktuellen Daten und Zustande 
ermeglicht einen genauen Einblick in die Hardware. Sofern der 
Zeitaufwand fttr die Simulation zu hoch ist und/oder die 100% 

15 Obereinstimmung des Simulators mit der Hardware fraglich ist r 
ermaglicht das Zurticklesen von Daten im Single-Step Modus 
nach Auftreten eines Breakpoints gem&JJ Methode A oder ent- 
sprechend des Kontext-Switch Verfahrens nach PACT 15 und 
PACT11 ein 100% korrektes Debugging des Algorithmus und/oder 

20 auch der Hardware selbst* 




7. Beschrexbttag der Flgttren . 

Figur 1 und 2 entsprechen der Patentanmeldung PACT11. Die un- 
25 terschiedlichen Ans&tze der Methoden A und B wurden in die 
Figuren eingezeichnet (A, B) 



Figur lib zeigt eine Representation des endlichen Automaten 
30 durch eine rekonf igurierbare Architektur nach PACT01 und 

PACT 04 (PACT 04 Fig. 12-15) . Das kombinatorischen Netz aus Fi- 
gur la (0101) wird durch eine Anordnung von PAEs 0107 ersetzt 
(0101b) . Das Register (0102) wird durch einen Speicher 

20 
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(0102b) ausgefvihrt, der mehrere Zyklen speichern kann. Die 
RUckkopplung gemafi 0105 erfolgt durch 0105b. Die Eing&nge 
(0103b bzw. 0104b) sind Equivalent 0103 bzw 0104. Der direkte 
Zugriff auf 0102b kann ggf- durch einen Bus durch das Array 
5 0101b realisiert werden. Der Ausgang 0106b ist wiederum Equi- 
valent 0106. 





Figur 2 zeigt die Abbildung eines endlichen Automaten auf ei- 
10 ne rekonfigurierbare Architektur. 0201 (x) reprasentieren das 
kombinatorische Netz (das entsprechend Figur lb als PAEs aus- 
gestaltet sein kann) . Es existiert ein oder mehrere Speicher 
ftir Operanden (0202) und ein oder mehrere Speicher far Ergeb- 
nisse (0203) ♦ 2us£tzlich Daten Ein-/Ausgange gem* 0103b, 
15 0104b, 0106b) sind der Einfachheit halber nicht dargestellt. 
Den Speichern zugeordnet ist jeweils ein Adressgenerator 
(0204, 0205). 

Die Operanden- und Ergebnisspeicher (0202, 0203) sind physi- 
kalisch oder virtuell derart miteinander verkoppelt, dafi bei- 

20 spielsweise die Ergebisse einer Funktion einer anderen als 

Operanden dienen kSnnen und/oder Ergebnisse und operanden ei- 
ner Funktion einer anderen als Operanden dienen konnen. Eine 
derartige Kopplung kann beispielsweise durch Bussysteme her- 
gestellt werden oder durch eine (Re) Konf iguration durch wei- 

25 che die Funktion und Vernetzung der Speicher mit den 0201 neu 
konfiguriert wird. 



Figrsir 3 zeigt eine mSgliche schematische Struktur des Debug- 
30 gings nach Methode 3. Es sei insbesondere beispielh&f t auf 
die Figuren 19, 20, 21 der Patentanmeldung PACT 13 verwiesen, 
in welcher die Grundlage der Speicher beschrieben ist. PACT 1 3 



2\ 
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wir hiermit zu Of fenbarungszwecken vollumf Snglich eingeglie- 
dert . 

0101b und 0102b ist wis bereits beschrieben dargestellt, Zu~ 
sStzlich ist eine externer Speichereinheit dargestellt 
5 (0302)/ der maglicherweise £hnlich PACT 13 an 0102b ange- 
schlossen (0307) sein kann. Es soli besonders darauf hinge- 
wiesen werden, dali sowohl 0102b als auch 0302 externe Oder 
interne Speichereinheiten sein kfcnnen. Ebenfalle soli eine 
Speichereinheit als mindestes ein Register, eine Menge von 
10 Registern Oder ein Speicher (RAM, Flash, o.a.) oder Massen- 
speicher (Festplatte, Band, o.a.) definiert sein. 

Die debuggende Einheit 0301 kann Breakpoints innerhalb 0101b 
setzen (0303), auf Basis derer der eigentliche Debug Vorgang 
ausgeldst wird. Durch das Erreichen eines Breakpoints wird 
eine Information (0304) an 0301 gesendet, die den Debug Vor- 
gang startet; zugleich werden auch alle 0101b interenen Vor- 
kehrungen zum Debuggen (z.B. ein Anhalten und/oder Verlangsa- 
men des Taktes) ausgel6st. Alternativ kann auch durch 0301 
die Information generiert und an 010 lb gesendet werden. 
Ober 0305 und/oder 0306 kann 0301 auf die Daten und/oder Zu- 
stSnde aus dem Speicher 0102b und/oder dem Speicher 0302 zu- 
greifen. Der Zugriff kann zum Beispiel 

1. durch eine Speicher koppiung (Block-Move, d.h. kopieren 
der Speicher in einen anderen, von 0301 kontrollierten 
Bereich) 

2* durch eine Leitung (serielle oder parallele Leitung, 
fiber die ein oder mehrere Speicherbereich (e) iibertragen 
wird/werden, z . B . JTAG) 
3. Buskopplungen gleich welcher Art (die Speicher werden 
ahnlich eines DMA-Verf ahren arbitriert und von 0301 ver- 
arbeitet) 
erfolgen. 

22 
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Als Beispiel wurde eine Figur aus PACT 13 gewahlt- Es soil 
ausdriicklich darauf hingewiesen warden, dafi grundlegend jedes 
Speicherverfahren und jede Speicher kopplung (Stack, Random- 
5 Access, FIFO, usw.) entsprechend boarbeitet werden kann. 

Die Figuren 4a und 4b 2©igen weitere mSglichen Ausgestaltun- 
gen und wurden aus der Patentanmeldung PACT28 entnoramen, die 
zu Offenbarungszwecken vollumfanglich eingegliedert 1st. 

10 Der Aufbau einer besonders bevorzugten VPU ist in Figur 4a 

dargestellt. Vorzugsweise hierarchische Konf igurationsmanager 
(CT's) (0401) steuern und verwalten eine Anordnung von rekon- 
figurierbaren Elementen (PACs) (0402). Den CT f s ist ein loka- 
ler Speicher fur die Konf igurationen zugeordnet (0403) . Der 

15 Speicher verfugt weiterhin uber ein Interface (0404) zu einem 
globalen Speicher, der die Konf igurationsdaten zur VerfUgung 
stellt.- ttber ein Interface (0405) sind die Konf igurationsab- 
lauft steuerbar. Ein Interface der rekonf igurierbaren Elemen- 
te (0402) zur Ablauf steuerung und Ereignisverwaltung (0406) 

20 ist vorhanden, ebenso ein Interface zum Datenaustausch 

(0407). Beipielsweise kann eine der CT f s als DB agieren. 

Figur 4b zeigt einen Ausschnitt aus einem beispielhaften CPU 
System, beispielsweise einem DSP des Types C6000 von Texas 

25 Instruments (0451)* Dargestellt sind Programmspeicher (0452), 
Datenspeicher (0453), beliebige Peripherie (0454) und EMIF 
(0455) . Ober einen Speicherbus (0456) und einem Peripheriebus 
(0457) ist eine VPU als Coprozessor integriert (0458). Ein 
DMA-Kontroller (EDMA) (0459) kann beliebige DMA-Transfers, 

30 beispielsweise 2wischen Speicher (0453) und VPU (0458) oder 
Speicher (0453) und Peripherie (0454) durchfUhren. In diesem 
Beispiel kann 0451 als DB arbeiten und insbesondere auch der 
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erf indungsgemafie Debugger mit dessem. Debugger gekoppelt 
und/oder in dlesen integriert sein. 

Figur 5a zeigt einen belspielhaften Hardwareaufbau, der zum 
5 Debugger! von rekonf igurierbaren Prozessoren benutzt werden 
kann. Hierzu wird ein gepipelinter Konf igurationsbus 0501 
verwendet, Shnlich dern aus PACT 17 bskannten. Die Pipeline ist 
iiber mehrere Registerstuf en (0502) in horizontaler und/oder 
vertikaler Richtung aufgebaut, urn hehere Taktf requenzen zu 
10 erreichen. Der gepipelinte Konf igurationsbus fuhrt zu den zu 
konfigurierenden Elementen (PAEs) (0503), um diese mit Konfi- 
gurationsdaten 2u versorgen. 

Fignr 5b zeigt beispielshaft die erf orderliche Erweiterung 

15 gema£ der vorliegenden Erfindung, Jede Registerstuf e (0502) 
dekrementiert den Zahlenwert (LATVAL) zum Ausgleich der La- 
tenz2eit um 1 (angedeutet durch -1) . Ebenso dekrementiert je- 
de PAE (0503)/ die bereits eine Taktsteuerinf ormation erhal- 
ten hat, diese pro Takt um 1 (angedeutet durch -1/T) - Auf die 

20 PAEs und insbesondere deren internen Register kann nunmehr 
nicht nur schreibend sondern auch lesend zugegriffen werden, 
z.B. ttber eine besondere Steuerleitung (RD) , um Debugdaten 
auszulesen, Zu schreibende und gelesene Daten durchlaufen in 
diesem Beispiel das Bussystem durch das Array 'aus PAEs von 

25 links nach rechts und in der untersten 2eile in Ruck- 

wartsrichtung. Der Konf igurationsbus ist weiterhin ttber Regi- 
sterstuf en (0505) pipelineartig zurtlckge fuhrt (0504) . In die- 
sem Beispiel kann eine ttbergeordnete Einheit (CT/Ladelogik, 
Hostprozessor) (0506) ebenso lesend und schreibend auf den 

30 Bus zugreifen, wie ein dediziertes Testinterf ace (0507) . Das 
Testinterf ace kann einen eigenen Testkontroller aufweisen und 
insbesondere kompatibel zu einem oder mehrern marktgangigen 
Testschnittstellen sein (z.B- JTAG, Tektronix, Rhode &Schwarz, 

24 
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etc) . Die Auswahl der bussteuernden Einheit erfolgt tlber eine 
Multiplexer/Demultlplexer-Einheit (0508) . m (0509 in Klam- 
mern und kursiv dargestellt) oder vor den Einheiten 0506 und 
0507 kann eine Schaltung zur RUckrechung der Herkunftsadresse 
(0509) von Debugdaten, die ttber 0504 eintreffen, vorgesehen 
sein. Die Adressberechnungen innerhalb des aufgezeigten Sy- 
stems geschehen wie folgt: Zunachst wird die Adresse durch 

0506 oder 0507 am Bus 0501 angelegt. Die Adresse wird ahnlich 
der Verarbeitung der Zahlenwerte (LATVAL) zur Latenzberech- 
nung in jeder Registerstufe (0502 und 0505) dekrementiert . 
Sobald die Adresse gleich 0 ist, wird die nach der Register- 
stufe liegende PAE selektiert. In der nachf olgenden Register- 
stufe wird die Adresse negativ, sodass keine weiteren PAEs 
mehr aktiviert werden. Sofern Daten aus einer PAE gelesen 
werden, werden diese zusammen mit der Adresse zurUckUbertra- 
gen. Die Adresse wird dabei in jeder Registerstufe weiter de- 
krementiert. Eine RUckrechnung in 0509 der bei 0506 und/oder 

0507 zusammen mit den Debugdaten eintreff enden Adressen ist 
nunmehr durch eine einfache Addition moglich, indem die An- 
zahl der dekrementierenden Registerstufen zu dem eintreffen- 
den Adresswert hinzuaddiert werden. Es soil angemerkt sein, 
dass die Registerstufen 0502 in Figur 5b leicht unterschied- 
lich gegentiber den Registerstufen 0502 in Figur 5a ausgestal- 
tet sind. In Figur 5b weisen diese namlich zusatzlich eine 

25 Schaltung (z.B. Multiplexer) zu Auswahl der weiterzuleitenden 
Daten auf, der entweder die Daten des Busses 0501 weiter- 
schaltet oder den Ausgang der zugeordneten PAE (0503) und so- 
mit die DebugDaten. Zur Ansteuerung der Schaltung kann das 
Auftreffen des Adresswertes gleich 0 dienen. 



Es wird nochmals darauf hingewiesen, dass das dedizierte Te- 
stinterface (0507) den Industriestandards entspricht. Es kann 
zu Tests wahrend des Sof tware-Debug-Vorgangs eingesetzt wer- 
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den und/oder zu Test wShrend des Zusatnmenbaus von Hardware- 
komponenten und -systemen (z.B. dem Zuaaotfnenbau der Schaltun- 
gen auf der Platine) und/oder zu Funktionstests des Halblei- 
terbausteins (Chips) ixn Rahmen der Halbleiterf ertigung. Ins- 
besondere dadurch kann. die abliche Scan-Chain zum Test der 
Register wahrend des Funktionstests des Halbleiters entfallen 
Oder zumindest entsprechend minimiert werden, da dann nur die 
Register durch die Scan-Chain gefiihrt werden mttssen, die 
nicht vora Bussystem (0501) ansteuerbar sind* 



Ebenfalls wird besonders darauf hingewiesen, dass das in Fi- 
gur 5 eriauterte Verfahren keinesfalls auf die Anwendung von 
Konfigurationabussen beschr&nkt ist. Gewohnliche Datenbussy- 
steme ktfnnen ebenso zu den unterschiedlichen vorab aufgezahl- 

!5 ten Test- und Debugging-Zeitpunkten und -arten verwendet wer- 
den. Insbesondere sei in diesem Zusammenhang auf das in 
PACT 07 beschriebene Datenbussystem hingewiesen. PACT 07 ist 
hierzu zu Of f enbarungs2wecken vollumfanglich eingegliedert . 
Die in Figur 5 beschriebenen Verfahren kSnnen, fur einen In- 

20 genieur mit gewShnlichen technischen Kenntnissen ieicht nach- 
vollziehbar ebenso auf PACT 07 angewendet werden. 
Ein Mischbetrieb unterschiedlicher Bussysteiue, wie Konfigura- 
tionsbussystemen, Datenbus systemen nach PACT 07 und gewahnli- 
chen Datenbussystemen ist desweiteren grunds&tzlich maglich. 

25 Dazu kSnnen mehrere Testinterf ace vorgesehen sein, Oder wie 
technisch bevorzugt die Multiplexer /Demultiplexerstuf e (0508) 
auf eine Mehrzahl von Bussystemen (n x 0501, n x 0504) ausge- 
legt werden, 



30 Abschliefiend soil noch besonders erwahnt sein r dass durch die 
Rttckftthrung des Bussystems nach Figur 5b auch die in die PAEs 
zu schreibenden Konf igurationsdaten zuriickgefiihrt werden. un- 
ter Zuhilfenahme der Adressrttckrechung (0509) und der zurtlck- 
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gefUhrten Statusleitung RE J, die nach PACT17, PACT10, PACT 05 
eine ZurOckweisung der Konfigurationsdaten anzeigt, kann auf 
die Verwendung der Konf igurationezwischenspeicher-FIFOs nach 
PACT 17 Figuren 8 und 9 (0805, 0903) verzichtet werden, da de- 
5 ren Funktionalit&t nunmehr vollumf Snglich tiber das beschrie- 
bene Bussystem abgebildet wird. 
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8 . Begrxf f sdef ini.t:ion 

lokal rsXevanter Zustand Zustand der nur innerhalb einer 

bestimmten Konf iguration relevant 1st 

5 

global relev r anter Zustand Zustand der in iuehreren Konfi- 
gurationen relevant 1st und zwischen den Konf igurationen aus- 
getauscht werden mufi 

!0 relevanter Zustand Zustand der innerhalb eines Algo- 

rithmic zur korrekten Ausftihrung dessen benatigt wird und so- 
mit durch den Algorithmus beschrieben 1st und verwendet wird 

irrelevanter Zustand Zustand der fu\r den eigent lichen Al- 
15 gorithmus ohne Bedeutung ist und auch nicht im Algorithmus 

beschrieben 1st, der jedoch von der ausftthrenden Hardware im- 
plementierungsabhangig benotigt wird 
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Patentansprttche 

20 Verfahren zum Debuggen von rekonf igurierbarer Hardware , da- 
durch gekennzeichnet, dafi sSmtliche notwendige Debuginf orma- 
tion je Konfigurationszyklus in einen Speicher geschrieben 
warden, der dann vom Debugger ausgewertet wird. 
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